We start by presenting some basic concepts to facilitate the understanding of the mechanisms that are presented further on.
Packets
Data networks usually split the data they carry into small units known as packets. Actual communication between endpoints is controlled by various communication protocols. Generally, each communication protocol required for data to be carried across a network such as the Internet requires the addition of a header containing any information required to enable the data exchange between the end hosts (usually a source host and a destination host) to take place. In relation to the Internet, one of the most common types of packet consists of a payload that contains data generated by an application running at the source, encapsulated by a Transmission Control Protocol (TCP) header which ensures the reliable delivery of the data, encapsulated again by an Internet Protocol (IP) header, which ensures that the data reaches the intended destination host. The TCP header includes a unique sequence number (to allow the data to be reconstructed at the destination), whereas the IP header includes the IP addresses of the source and destination host.
Multi-Path Transport
One of the original design goals of packet networks was to ensure that for data that has been split into packets, the paths taken by respective packets through a network were not critical, and need not all be the same; irrespective of these issues, it should be possible for the original message to be re-constructed at (or for) the receiver by re-assembling the packets in the correct order. However, in the Internet as it is currently implemented, packets in a flow generally all follow the same path unless there is a problem (e.g. node failure, etc). The presence of multiple paths through a network therefore acts primarily as a mechanism for resilience. Currently research is being done in relation to adding multi-path support into TCP. As will be discussed later, various versions of multi-path transport control protocols have been proposed, such as the following: MPTCP, mTCP, pTCP.
DiffServ (and IntServ)
DiffServ (which term refers to the concept of “Differentiated Services”) is a coarse-grained, class-based mechanism for traffic management. In contrast, IntServ (“Integrated Services”) is a fine-grained, flow-based mechanism.
DiffServ operates on the principle of traffic classification, where each data packet is placed into a limited number of traffic classes, rather than differentiating network traffic based on the requirements of an individual flow. Each router in the network is configured to differentiate traffic based on its traffic class. Each traffic class can be managed differently, ensuring preferential treatment for higher-priority traffic traversing the network.
The DiffServ model does not incorporate pre-made judgements relating to what types of traffic should be given priority treatment; such judgements may be made by the network operator. DiffServ simply provides a framework to allow for classification and differentiated treatment. DiffServ does recommend a standardised set of traffic classes (discussed below) to make interoperability between different networks and different vendors' equipment simpler.
DiffServ relies on a mechanism to classify and mark packets as belonging to a specific class. DiffServ-aware routers implement Per-Hop Behaviours (PHBs), which define the packet forwarding properties associated with a particular class of traffic. Different PHBs may be defined to offer, for example, low-loss, low-latency forwarding properties or “best-effort” forwarding properties. All the traffic flowing through a particular router that belongs to the same class is referred to as a Behaviour Aggregate (BA).
In practice though, most networks use the following commonly-defined Per-Hop Behaviours:                “Default PHB”—this is typically “best-effort” traffic.        “Expedited Forwarding” (EF) PHB—generally dedicated to low-loss, low-latency traffic.        “Assured Forwarding” (AF) PHB—this gives assurance of delivery under certain conditions.        “Class Selector” PHBs—these are defined to maintain backward compatibility with the IP Precedence field.        
TCP Bandwidth Sensing and Congestion Control
Standard TCP (known as TCP Reno) uses loss-based congestion control. A flow starts and attempts to increase its sending rate until a loss event occurs; at which time it reduces its sending rate. TCP allows for two phases:                “Slow-Start”; and        “Congestion Avoidance”.        
A TCP flow starts with “Slow-Start” (also known as the “exponential growth” phase). During this phase, the TCP congestion window is increased each time an acknowledgment is received from a receiver. The window size is increased in dependence on the number of segments acknowledged (where each segment may be one packet, or several packets). This happens either until an acknowledgment is noted not to have been received for some segment or until a predetermined threshold value is reached. If a loss event occurs, TCP assumes that this is due to network congestion—steps are then taken to reduce the offered load on the network.
Once a loss event has occurred or the threshold has been reached, TCP enters the “Congestion Avoidance (or “linear growth”) phase. At this point, the TCP congestion window is increased by one segment for each round-trip time (RTT). This happens until a loss event occurs.
Flash Video Streaming
Adobe Flash (both words of which are used as registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries) works typically by sending bursts of data from the sender to the receiver until the buffer on the receiver is full. The sender then stops sending, waits and then sends another burst of data from its buffer until it receives an indication from the receiver that the receive buffer is full again. During the sending phase, the data is being transferred more quickly than the play-out rate; the data is generally sent as fast as possible according to what TCP has determined its rate can be.